OpenEdge Development:<br />Progress Dynamics Basic Development Using PLIPs versus SDO logic procedures

A basic question in the mind of any developer will be when to use which mechanism for application logic. Chapter 10, "Building Basic Business Logic in a Progress Dynamics Application," introduces you to the logic procedure for SDOs, which is itself a PLIP. The "Transaction scoping within procedures" section discusses the use of the PLIP for other kinds of logic. Absolute guidelines are difficult to arrive at, since they depend on the style and structure of a particular application and on the extent to which existing application logic is being repackaged for use within a Progress Dynamics application. Nonetheless, it is important to make some general recommendations.

First, either put logic directly related to the update of a table into the logic procedure for its SDO or access it from there. Wherever possible, use the standard validation procedure hooks for this purpose. The phrase “access it from there” is to remind you that the principle of “putting logic in the SDO” does not at all mean that the code must be literally part of the SDO source procedure, or for that matter, its new logic procedure. It means that those entry points are a useful way to organize access to logic. If you have existing procedures that do largely the same work in the context of an older application, then by all means reuse them. Call them from appropriate entry points in the SDO, and the logic will happen at the right time.

The SDO logic procedure itself is a PLIP. This means that it can be run and its logic accessed independently of the SDO with which it is associated; this is part of the reason for creating it and maintaining it separately. If you need to access some of that logic from the client or from elsewhere on the server, you can do so using the launch.i mechanism. Earlier, this chapter recommended against using the technique of obtaining the AppServer handle through the getASHandle function and running SDO procedures directly in that way. Instead, in the same situation, the client code can simply use launch.i to invoke the logic through the Session Manager. In this way, the Session Manager will take care of locating the server-side procedure (which might already be running), run the right internal procedure, return the results, and remove the connection.

A logic procedure PLIP can certainly contain procedures other than those that are already recognized as standard validation hooks, if they pertain to the SDO the procedure supports, just as an SDO today can contain additional logic procedures. If you have business logic that is broader in its scope than a single SDO, that can and should go into a PLIP of its own, which can be located on an AppServer and run as needed from any client. There is no absolute rule for the right granularity for such procedures, any more than for Progress procedures in general. Sensible guidelines apply. Internal procedures that are directly related should be grouped into a single PLIP, as long as the size does not get out of hand. It will normally be necessary to start a PLIP for each access from a client. Therefore, you should avoid very large procedures when you can easily break them up. Also, if the contents of a large procedure are not directly related to one another, you might find one day that they really belong on different AppServers, which would force you to break up the procedure. In general, make your PLIPs as small as is reasonable to keep essential logic together, but no larger.

Use the SDO and SBO entry points (defined for you) for logic that will be executed at some point in the update process for a record or a set of related records. Put validation logic for an SDO into its logic procedure or run it from the appropriate SDO logic procedure entry point.

Avoid making extra calls from an SDO client to an SDO on the server. If you must access logic in the server from some point in the client application, use launch.i to let the Session Manager control the connection for you. You can use launch.i to access the logic procedure of an SDO as well as any other PLIP.

Package logic that does not fit neatly into the validation hooks of the SDO or SBO into separate external procedures (.p files) as PLIPs, using the Structured PLIP template as the starting point. This logic can be run from SDOs and SBOs, from the client application, or from other procedures on the server.

Put related entry points into the same PLIP, but keep the size of the overall procedures modest so that there is minimal overhead in starting the procedures.

If you have done any work to create business logic procedures that are independent of the user interface of your existing application, you might be able to repackage that logic into PLIPs with minimal effort. If you recast existing procedures using the PLIP template and create internal procedures that correspond to existing internal or external procedure names in your application logic, you will be setting your new application up to manage such logic effectively through the Session Manager.